\documentclass[12pt,A4Paper]{report}
\usepackage{graphicx}
\usepackage{amsmath}
 
\parindent 0pt
\parskip 6pt

\begin{document}

\graphicspath{C:/Users/Matt/My Documents/!University
Work/CompSci/workspace/PartII/gr/}

\chapter{Introduction}

In this project I create an OSI layer 2 for Android that allows data to be
transferred using audible sound, which I will refer to as \emph{Dolphin}. All
five of the original success criteria have been achieved, as well as one of the
two extensions. Effective data transfer rates achieved mean the technique will
not be a suitable substitute for WiFi or USB transfer. This should instead be
used when the amount of information to send is very small (such as a
\emph{vCard}), an Internet connection is unavailable and techniques such as
Bluetooth pairing would be too slow.

\section{Motivation}

With more and more people owning smart phones the need to transfer information
between devices has become a larger issue. Some example methods of data transfer
include: multimedia messaging; infrared; bluetooth; WiFi; and 3G. A more recent
method of transferring small text messages, such as internet links, is through a
\emph{Quick Response} (QR) code, which is scanned and decoded using the phone's
camera and a dedicated application. These QR codes have become increasingly
popular~\cite{QRPopularity}, not only in phone to phone data transfer but also
in advertising.

The weaknesses of QR codes are the need to be close enough
to the code to accurately scan it, so for long distances the code needs to be made
very large, and needing to hold the camera still enough to scan the image, which
is not always possible in a crowd or in a moving vehicle. They can also only
contain a small amount of information: 4000 alphanumeric
``words"~\cite{QRSize}.
This cannot be used for transferring larger files and most QR programs that
offer large file transfer opt instead to upload the file to a webserver and encode the
link in the QR code. Dolphin can be used to create QR code-like sequences
which use audible rather than visual stimuli to encode the data, and has no
limits on the maximum file size.

Using sound as the transmission medium means larger files can be encoded
using longer sounds which is more feasible than implementing an ever
increasing size QR code. There is a limit on the amount of information a QR
code can contain as the entire code must be in the camera's frame at once
and the dots that comprise the code need to be large enough to be
detected by the camera. The largest QR code developed to date contains 177 rows
and columns and can theoretically hold 4296 alphanumeric characters. Smaller
dots are also more difficult to scan than larger dots with a moving camera.
With Dolphin, there is no need to hold the receiving device steady and noise
cancellation techniques can be applied to the system in the same way image
stabilisation can for QR codes. Furthermore, if the receiving device is further
away from the transmitter you simply need to increase the volume rather than
print a larger QR code. For a real-world example, the link to a band's latest
album could be encoded and played through the sound system at a concert, which
will be loud enough to reach the back of the crowd as they otherwise wouldn't be
able to hear the music. However, assuming a smartphone camera has an effective
viewing range of 1:10 (so a 2cm QR code can be effectively read up to a distance
of 20cm) and a concert location size of 500 metres, to be read at the
back the QR code printed would need to be 50m across, which would be difficult
to erect.

Dolphin uses the data-link layer as higher layers can access the
functionality of the concept. The advantage over an application layer sound
transfer system is that other applications would be harder to integrate this
into and it would be less useful. This way Android app programmers can use
the data-link layer to implement file transfer systems, QR code style sounds,
discreet text communication systems, and more.

\section{Android and Java}

I use Android for this project, rather than one of the other
major mobile OS providers, because Android is open source and has an expressive
API online. This means it is easier to access the underlying hardware on the
phone such as the microphone and speakers, and app programmers have more freedom
to use this layer in their projects. Android also uses Java which has numerous
built-in libraries and custom libraries that will prove useful.

\section{Encoding and decoding}

Every file on a computer has a binary representation. Therefore, Dolphin encodes
any sequence of bytes, regardless of what they represent, in order to ensure
that any computer file can be successfully transmitted. Each bit pattern that
makes up a byte is assigned a unique frequency, meaning every file can be
portrayed as a series of 255 possible frequencies. Different frequencies sound
different when they are played, so the encoding process is reversible by
analysing what the unique frequency of the sound is. To determine the frequency
of a sound I use a Fast Fourier Transform to sort the recorded data into an
array of amplitudes at each frequency, and then the largest amplitude is taken
as the one that was sent.

\section{Results}

The evaluation reveals that Dolphin is capable of 100\% accuracy in data
transfer, using a sample rate of 32kHz and encoding each byte of information in
a 64ms burst of sound. Frequencies representing bytes are spaced 30Hz apart so
they can be more reliably decoded.

\section{Project summary}

In Chapter 2 I discuss the background knowledge required for implementing this
project, including sound theory, how to decode signals and some existing work
that does similar things. I also outline my requirements analysis, describe a
testing strategy and detail the software development methodology I use, including how I have incorporated
version control in my work. I also briefly outline the Android application lifecycle as
Dolphin uses Android and all testing takes place using an Android app.

In Chapter 3 I describe specifically how I encode data as sound and then decode
it again. This includes the subtle differences between Java and Android
programming in this field and the complications that need to be addressed when
programming a mobile app for Android. I also describe the existing libraries I
make use of to complete the work and present some results of the ongoing testing
that took place during the software development.

In Chapter 4 I show how the original criteria were achieved using the test plan
in Chapter 2. I present a more detailed account of the tests that produced the
results described at the end of Chapter 3 and use the results to carry out a
significant improvement to the implementation. A comparison between the original
design and the new version is then presented.

\end{document}